Summary
A working map of 19 skills for staff-level engineering, grouped into four areas: choosing direction, delivering sound technical change, making collective work effective, and making outcomes last. It starts from a base list of 15 broadly valuable skills, translated into engineering practice, and adds four capabilities the role depends on: verification, delivery planning, technical communication, and developing other owners. Each skill comes with a concrete way to practise it.
## Background
The starting point was a list of 15 broadly valuable human skills. All 15 apply to staff engineering, so the note keeps all of them. Each one is restated in engineering terms, and four capabilities that a staff engineer depends on are added.
One item needed reframing. *Institutional creation* becomes **creating durable engineering structures**, such as ownership models and decision processes. How much it matters depends on your scope.
A note on the evidence
The original list came with forecasts of how long each skill would stay a human advantage. Those percentages are left out on purpose. The research supports these skills being useful, but it does not show that humans will keep a long-term advantage over AI in them.
## Overview
| Group | Focus | Skills |
|---|---|---|
| **1. Choose worthwhile problems and direction** | Deciding what is worth doing and why | 1-5 |
| **2. Understand systems, establish evidence, and deliver changes** | Getting the technical substance right and shipping it | 6-10 |
| **3. Make collective engineering work effective** | Working through and with other people | 11-17 |
| **4. Make outcomes and improvements last** | Following through and leaving durable structures behind | 18-19 |
## 1. Choose worthwhile problems and direction
| Skill | What it means in staff engineering | How to develop it |
|---|---|---|
| **1. Objective setting and prioritisation** | Decide which outcomes deserve investment, what success means, and which constraints must hold. | Write a brief explaining the desired outcome, success measures, alternatives, and why this work deserves attention now. |
| **2. Problem discovery** | Find overlooked user pain, operational risks, wasted effort, and opportunities that have not reached the backlog. | Observe users or operators doing real work. Investigate a recurring workaround and establish its actual cost or consequence. |
| **3. Problem reframing** | Recognise when the stated problem is a symptom, an unnecessary constraint, or an assumed solution. | For a stalled initiative, write two alternative problem definitions. Gather evidence to determine which leads to a more useful intervention. |
| **4. Judgment under uncertainty** | Make consequential decisions when evidence is incomplete and reliable probabilities are unavailable. | Compare plausible scenarios, downside, reversibility, and the cost of waiting. Record what evidence would make you change course. |
| **5. Technical taste and discernment** | Recognise designs that are coherent, understandable, maintainable, and appropriate to their purpose. | Compare competing designs using explicit quality criteria. Explain which complexity you would remove, which you would accept, and why. |
These five break the broad capability of "problem framing and prioritisation" into distinct practices. Will Larson's guide to writing engineering strategy makes the same connection between concrete problems, alternatives, tradeoffs, and explicit rationale.[^strategy]
## 2. Understand systems, establish evidence, and deliver changes
| Skill | What it means in staff engineering | How to develop it |
|---|---|---|
| **6. Systems thinking and architecture** | Design boundaries and interactions while accounting for data, failure modes, ownership, incentives, and downstream consequences. | Trace a proposed change across the system and its teams. Identify hidden assumptions before choosing interfaces and responsibilities. |
| **7. First-principles reasoning** | Separate genuine constraints from inherited conventions, then reconstruct the reasoning behind a solution. | Revisit one important design choice from its requirements, technical limits, and costs. Check whether the existing pattern still fits. |
| **8. Empirical investigation and experimentation** | Create useful knowledge through debugging, measurement, observation, and experiments. | Write competing hypotheses for a real problem, choose a test that distinguishes them, and update your explanation from the result. |
| **9. Verification and risk assessment** | Determine what must be true and what evidence justifies accepting a change. | For a consequential change, list required properties, supporting checks, and remaining uncertainty. Strengthen the weakest important check. |
| **10. Migration and delivery planning** | Turn a design into a completed transition, including compatibility, rollout, recovery, adoption, and retirement. | Break a migration into verifiable stages. Give each stage acceptance criteria, an owner, and a recovery path; define when the old system disappears. |
Technical depth underpins this whole group
You need enough understanding of the implementation, your domain, and operational behaviour to challenge explanations and test predictions. Architecture, investigation, verification, and release engineering each have their own established foundations. Broad reasoning skills do not replace them.
Architectural mismatch is a good example of what that depth catches. Garlan, Allen, and Ockerbloom found that reused components often fail to fit together because each one makes implicit, conflicting assumptions about the system around it.[^mismatch]
## 3. Make collective engineering work effective
| Skill | What it means in staff engineering | How to develop it |
|---|---|---|
| **11. Contextual and organisational understanding** | Understand the history, incentives, informal dependencies, and constraints behind what people say and do. | Before proposing a change, ask affected teams what previous attempts encountered and what would make adoption difficult. Check your interpretation with them. |
| **12. Clear technical communication** | Make intent, tradeoffs, system behaviour, and decision rationale understandable enough for others to act. | Explain a real decision through a short document, diagram, or example. Ask an unfamiliar colleague to use it to answer a practical change question. |
| **13. Cross-team coordination** | Make interdependent work fit together through clear ownership, sequencing, interfaces, and commitments. | Map one initiative's dependencies and resolve its largest ownership or sequencing gap. Check whether blocked work resumes. |
| **14. Trust and relationship building** | Establish credibility through reliable follow-through, candour, sound judgment, and understanding others' concerns. | Make explicit commitments, communicate risks early, acknowledge mistakes, and close the loop with the people affected. |
| **15. Negotiation and coalition building** | Reach workable agreements when teams have different priorities, costs, or incentives. | Identify each party's needs and constraints. Develop options that distribute costs fairly, then secure explicit commitments from the people needed to execute. |
| **16. Technical leadership and commitment** | Give people a credible direction and sustain coordinated action while uncertainty remains. | Lead a bounded initiative with a clear purpose, near-term commitments, and review points. Revise the plan when evidence changes. |
| **17. Delegation and developing independent owners** | Expand the number of people who can make sound decisions and own consequential work. | Transfer a bounded responsibility with context, authority, and escalation boundaries. Assess whether the new owner can handle an unfamiliar variation independently. |
Accounts of staff roles, along with research on coordination and onboarding, support treating these as separate contributions rather than one general "people skill".[^archetypes] [Key distinctions](#key-distinctions) below sets out how they differ.
## 4. Make outcomes and improvements last
| Skill | What it means in staff engineering | How to develop it |
|---|---|---|
| **18. Accountability and ownership** | Follow consequential work through to its actual outcome, including operation, mistakes, and corrective action. | Define what you own and how success will be checked after launch. Review the result and close unresolved consequences instead of treating release as completion. |
| **19. Creating effective engineering structures** | Establish durable ownership, standards, decision rights, working groups, or collaboration arrangements where existing structures fail. | Address one recurring gap with the smallest workable arrangement. Give it a purpose, owner, and review date; keep it only if it improves outcomes. |
Skill 19 is the staff-engineering form of *institutional creation*. It matters most when recurring problems require changes to how engineering operates. Creating new organisations or markets is not a general staff requirement. Will Larson's guide to managing technical quality includes creating teams and quality programmes, and warns against introducing process too early.[^quality]
## Key distinctions
Several of these skills sound alike but do different jobs:
- **Communication** creates understanding.
- **Coordination** connects work.
- **Negotiation** changes commitments.
- **Trust** supports cooperation.
- **Leadership** supplies direction.
- **Delegation** increases independent ownership.
## How to use this list
Use it as a development menu, not a checklist
Judge improvement by the result, not by how many skills you can claim.
1. Pick the skill connected to a **recurring, consequential problem** in your current work.
2. Practise it on that problem, using the "How to develop it" column as a starting point.
3. Review the outcome, then pick the next skill the same way.
## References
[^strategy]: Will Larson, "Writing engineering strategy", StaffEng.
[^mismatch]: David Garlan, Robert Allen, and John Ockerbloom, "Architectural Mismatch: Why Reuse Is So Hard", *IEEE Software*, 1995.
[^archetypes]: Will Larson, "Staff archetypes", StaffEng.
[^quality]: Will Larson, "Manage technical quality", StaffEng.